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m\ Abstract Title: Propagation el yteses throogh an ml carnation technology nstwsj: k 

{87} Reqoeats to sen<S dsta from a hrst host within a network of hosts ars monilomd against a rs^hiof 

destination hosts who have been sent dais In accordance with a predetor mined policy. Desttehon host 
kkmUttes notth^ record are stored in u'buffitt/The buffer s&e monitored to estab&sh whether requests 
from the first hom. arc pur^nanr to viral activity. An embodiment of the invention d&ck>soa a computing 
entity, adapted to process « request to ■■standi an .wnmi to ■ irm\Uph$ mdpUmi^ : h% comparing the manner of 
reoipkmts in the rsquestwith the vaiyc of a parameter, I'nhjb^tjn^/f nt^ing : tnmsrnf&Mpn of the m$s&$g0- 
to at soms. #f the rmnmnU, mifmtm® the value of tho parameter m accordance with a pojfoy by 
redoomg ft with each tmnsmbsion of e request to a destff>abon host, and in^remommg it. with the passage 
of m$$$ thee inter vat in which no requests are tran^rviitted. 
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PROPAGATION OF VIRUSES IBROUGH AN INFORMATION TECHNOLOGY 

NETWORK 

The present invention relates to fee propagation of viruses "through a network of 
5 toiefcomiected processing entities. 

In current network ravfets^csnts virtually any processing entity (or "host*') is M oim 
itnw. m mothm: connected to one or more other hosts. Thm for example m iM cm ®$ 
m IT environment^ a host in the ■■form, of a .computer |$uch as a client, a server, a router, 

W or even .a printer for sample) is fluently connected to one or more other computers, 
whether within an iMnmet of a commercial organisation, m mpM0fiWM4m^t 
Alt^Etivelyv irrtlie ease of a conimunkations lechnology environment, a host in the 
Mm of a mobile telephone i% merely by virtue of .its intrinsic purpose, going to he 
eonneclcd to one or more other hosts from time to time, arid an inevitable result Is |M 

IS the oppoitmiife for the propagation of vimses are enhanced as a result For example 
in the case of a compute vims known as the "Code Re<T virus, once assnnifeted 
within a host the: vims operates to generate internet Protocol CtF*} addresses of other 
potential hosts at random, and then instructs the host to send a copy of the virus la each 
of these randomly-generated IP addresses. Although no t all of the potential feosfe are 

20 genuine (since the IF addresses aro randomly generated), sufficient of the randomly 
generated addresses are real addresses of further hosts to enable the virus to self 
propagate rapidly through the Internet, and as a result to cause a substantial drop in 
perfdrniance of many commercial enterprise's computing infrastractu.ro 

25 Within the content of tills speeifeatte a virus is data which is assimilahk by a host 
that may cause a deleterious eSeei u$k>n the performanee of ettherrthc aforesaid host; 
one or more other hosts; or a network of which any of the aho ve -mentioii ed hos ts are a 
part, A eharactenstic effect of a virus is that it pmpagates either throu|h self- 
propagation or through human interaction. Thus fer sample, a virus may act by 

30 becoming assimilated within a first host, and subsequent to its assimilation m ay thesi 
ea^ae deleterbus elleels witMn that first host, such as corruption and/br delettarof 
files. In addition the virus may cMse seI%ropagation to one or more ferfher h&sts at 
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•which it will fen cause -similar cotm^ 

AiteiBati^ely the vinxs rmy mere Sy he assimilated within iM first host ami cause no 
deleterious e ffects whatsoever until it is propagated to one or 1110m felbcr hosts where 
I! may then cause sneh deleterious e fleets such as, for example, corruption ami/or 
deletion of fi fe fo yet a forther aiteniative scenario; & vims may for mample feecornc 
assimilated within a first host, and then cause itself to be propagated to multlpk other 
hosts within the network. The virus may have no dcMimom effect npon of the 
hosts hy whom it is assimilated, however the sel%ropagaHon through the network per 
se may be of a sufficient m^gmtpde. to have a negative effect on the speed of ^genuine* * 
network traffic, so that ihe performance of the network is nonetheless affected m a 
deleterious mazier.. Ihe three examples given above are intended for illustration of 
the breadth of the tern) virus, ami are not intended to be regarded in my vmy m 
exeiusi vel y definitive, 

i has been established that in situations where viruses are likely to cause deleterious: 
effects upon either one or more hosts, or ihe network intrastmcture as a whole, one of 
the most important parameters in attempting to limit and then to reverse such elfoeis is 
the speed of propagation of a virus. Hnmao responses to events are typ ically one or 
more orders of snagnlMfc slower than the propagation speeds of viruses, and so 
substantial diflo^ arise within a network before any human 

network administrator is either aware of the problem, or capable of doing aching to 
remedy it Therefore any reduction in the initial rate of propagation of a virus through 
a network is liMy to he of benefit to Mtempts to limit any negative e&etSvar^r to 
remedy thent 

One existing and relatively popular appm&ch to taeiling the problems of virus 
propagation within a network may be though t of as an absolutist approach, ¥iral 
i&fet^ virus-ehse&ing software, which attempts to eheek ah 

ine#M'ng for sxasnpie uxmt . attaehmeBis, If subsequently a virus is discovered 
within a host, that host l.$:t>peally removed i&m the network iminediately, and 
disinfected once the natiire of the virus has been established In accordance w ith this 
philosophy each host may he thought of as cpntnbuting to protecting the network 



agalost widespread Infection and secondly m 

the event of infection, by Its sacrificial trnmal from the #twork> 

The present invention provider alterative approaches to infection and propagation of 
v%^es m a network -af hoslt?. The mveptiM k mt out in tfee claims. 

Embodiments of the invention will now be described, by way of example* and with 
inference to the a&companymg drawings, In which: 

Fig. I is a schematic representation of one form of network architecture; 

Fig, 2 is a schematic illustration of the conventional operational architecim^of a 
computing entity : fotmmg a part o£ for example, the network of Fig. I ; 

Fig. 3 & a schematic iOnstration of establishment of a connection in accordance with 
an application protocol from fig. 2; 

Fig. 4 is a schematic illustra tion of data transmission in accordance wi th a further 
application protocol from Fig. 2; 

fig- 5 k a schematic illi^tmlion of m operational architecture according to an 
embodimrat of iho present invention of a computing entity forming a part of a 
network; 

Mg> 6 k a graphical representation of the operation of a method according to an 
embodiment; 

Fig, 7 is a flowcl^rt i!kstmt$Eg the opeiatbn ^fthe nie&od of Figs, 6: 

Figs. E A and B are Soweharts i II miraling further aspects of emhodlMents of methods; 

fig; 9 is a seh^Batic description illustration of ari inibrmation technology network; 
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Wigs, tMi-0 are scfeenmtie r. IHiisl^atijpEfis ~oC nes^^rk . tmfflo from a first host of the 
network ill ustrate In Fig. 9, and the man agement of such network traffic; 

Hg. 1 1 is a flow chmX ilius tratfeg operation, of am aspect of a method aeeo to o»e 
s etnBodiment; 

Figs, 1 2 A and B are flaw charts illustrating the operation of ferlher aspects of a 
method; 

l o tigs, 1 3 AC illustrate a method according to a &rther embodiment; 

Fig, iAim flowchart of ^ of method iltostrsled in 

Hgv I3C; and 

15 Figure 15 is a flow chart of stops iitosiTmtmg the operation of a furthtt embodiment 

Refexing now to Fig.. 1, one typical form of network mcliKte a plurality of client 
eopputmg eaifes 10* and & of which is connected to 

a network backbone 30, in the present emmple, each of the compiMing tndties has a 
20 similar architecture enabling dispatch and receipt of data from oilier entities connected 
to the network, Referfeg bow to Fig, 2, e ach of the ^ 

thought of as three functional parts r one or more application programs 100, which in 
general terms may be ■ thoaght of as enabling irnpleme^iatioiiof a particular task thai a 
mm of the entity may wish to perform, such as browsing the Memot, word processing 

25 and so on; hardware 300 (si3eh as a haM drive 310, memory 320, a processor 330, .and 
a network card 340); 'm$m . operating system 200, The operating system 200 may be 
thought ofi in pari, as an interface 3?#?een the .applications program and the 
hardware, p^ib^Bfeg schaduli ng of ta^s quired by applications prograiBS, and 
allofe&tes jimmory and storage space amongst other thlnp. T& operating system 200 

B O may, in accordance wife this way of de^cribmg ike architecfere of a compnting entity, 
also indade a hierax^hy, or stack 400 of progmnis wMcli provide tiie entity in question 
wife the ability to dispatch and receive data to and fern other entities in the network, 
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in mcotimm with a timber of diSorem sets of femial riiks go^emkg the 
.tra^m&sioB of data mmm a network, known as prMocofe> !k$ network stack 400 
may be tteuglit ofm being, kseftf 4 kto the o$>eratmg system so that the two opiate in 
eonjunetion with each ate. The stack 400 include a strata of low level pmgrams 
■s wMdrprc^ level protocols 404, concerned for 

example with the formation of bundles of data kno Wit as * ■ packets** (which will be 
■discussed in more detail later), the order i& wMeh byte of data to be sent an4 
where appropriate* error detection and correction, A farther, high level strata of 
protocols usually implemented within applications programs ("application protocols**)* 

10 apply m conjunction with the low level protocols to provide for the dispatch and 
receipi of ciats at the behest of application propams. In the preset example the 
application program isses four different high level protocols 402; ETSP (real lime 
streaming proloco!)^ FTP (file transfer protocol)^ SMTP (simple mail transfer protocol 
- used lor email), and HTTP (hyper text transfer pK)t0eol - used pnmanly in internet 

IS related appifcatiom), and the operating system implements two low level protocols 
404: UDP (User Datagram Protocol for use with RTSPX and TGP (Transfer Control 
Protocol for use with tire remaiomg three application protocols), both low level 
protocols being implemented above, and in Internet Protocol (IF). 

Finaliv, the network Maek 400 iocludes a system program known as a driver 410 for 

20 the network can!, which m essence Is low level saSware tM! controls the network 
erf. 

In the present itlnstnited examples, the process of estabhshmg a connection m 

wife HTTP will fee considered Usually a request for such a connection is 

25 made by the web browser application pmgram, and this In turn is most likely to he at 
the behest of a mm: operating the weh browser. WMte tins is the ease, the request will 
identify the address or ''URL/' within the network of the computing entity with which a 
eoimeetion is sought, initially using ajphanumerie ^haraete^s entered at the address bar 
of the browser appUeahon program (lor example Ultimately 

30 howe ver ires^ are 'Tesol ved" into a numerical s iP address" of the form.; 

mmxM,m s where %%% i s an integer between 0 and 255 inel usive* An example of 
an IP address is 1 92 < 1 68 2 X The IP address is subsequently ihrthor resolved into what 
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is known as. a physical, or Media Access Control ( ■ *MACH address of the network cart 
of the destination competing entity. Resolution of the URL Into m IP. address, and the 
IP acMress to ft MAC address usually takes place at dedicated computing cities; 
within fee network, in a maimer which is well known per se 5 and wilt not be described 
s. furifcer herein. This d^cription of the eonneo ii m process f ft accordance wife HTTP, 
well known per m ? has described eonnecdons legitimately requested by a user, and by 
means of a tJEU However it should fee appreciated tot ii is possible for exaniple to 
request i\ mrnmction from the weh browser application program using an IP address, 
rather than the alphanumeric diameters o f the URL, This is an aspect of the system 
1 0 behavtonr which has been exploited by viruses, some of which randomly gmerate IF 
addresses in accordance with the rules governing their allowable fonnat, and then seek 
connection to those randomly generated addresses. 

In the context of ibe present application it should be appreciated that the term 

IS "'conneenoo^ is a term of art, and is used to refer to a manner of transmitting messages 
in which acloiowlcdgemeiit of receipt of data is required, so that in the absence of an 
acknowledgement the conBection is deemed either not to h«e been established, or to 
have Mk4 aad: the transnntled message deemed not to have arrived. One apptfcatioft 
protocol which operates using connections is HTTP, and an example o f the 

20 establishment of a HTTP will now be described with 

sxfeenee to Figs, 2 and 3. A conneetioM in accordance with If FTP is typically 
established at the behest of a weh bnowser apiiication pnagmni (f e, a program in the 
applications layer 100 in Fig. 2} within the client entity, which requests a connection 
with a server entity, for example. When m application program snch as a web browser 

as seeks to establish a connection with another computing entity, & hii tially req wsts what 
is teowB as a socfet 450 from the operating system, A socket is effectively an 
allocated memory space in which dala relating to the eommimicMion sought by the 
web browser (in this instance) is stored Upon receiving a request tor a sockets the 
operating system duly creates or * s opemT one (which in effict means that memory is 

3D allocated}, and returns a socket number, which is the identifier for that particniar 
socket In Fig, 2 the f articular socket is indicated by reference nomeral 450 ? and the 
number of the socket Is whil e the part of the operating system which allocates fee 
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siKste is shown as a -**kyer ? ■ above the aetwork stack, by which It k sought to Wicale 
that, from a melhodotogic^ perspective, use of the (further uses of wMch will 
subsequently bcj described) in the case of outgoing data* pn^edes fee passage of data 
from the application program through the network stack. Once a socket has been 
5 opened, the web browser feeti roque^fe thai the socket z is^ound** firstly to the IP 
address with which a connection Is sought, and secondly is a parameter known as the 
"port^ number (which Is essentially a label identifying the apphoaion protocol nsod), 
by writing these parameters m Iho socket (which in dne course will additionally 
contain further data). The port nmnber for conn^iions via II1TP is usually port 80, 

10 Once, a socket has been created and hound the browser then requests that a connection 
be established, and thi s causes the emission of what is town as a data packet P3 Q 
(shown in Fig 3} to the destination computing en tity> The requesting pacte PX0 
contains; an identification of the destination port* Le. an IdeMi&adon of the suitable 
application protocol for handling messages transmitted over the requested connection 

IS (here, because the emmeetion is established in accordance with HTTP, port 80); a 

source port (here 3167) which is M arbitrary nuniber (but one which is not: (i) already 
in use at that time, and (ii) not already allocated as a standard number to define a port 
iderfSed in accordance with established standards) whose purpose is to provide, to the 
dieM revesting the connection, an identification o f the cnmwti on in 

2 o acknowledgement messages (e.g. , since it is tnimbf possible that tfeere may 

sininltaneousiy be two are more connections using the same protocol Ibis may be used 
to tlistingnish one s^eb connection ftoni the otter); a flag indicating feat the 
synchmnisata status of the requesting entity is set to 4 W (meaning that sequence 
numbers - which indicate the order of the packet in a total number of packets sent * 
2 5 between tbe requesting and destination computing entity m to he synchronised), and 
an initial sequence number 50 (this could be any number % Upon receipt of this packet, 
the destination machine sends back a packet B20 identifying tbe source port as 80 r the 
destination port as 31 &% & lag indicating that the acknowledgement status m %tf\ m 
acknowledgement number SI which augments the sequence n umber by one^ and its 

3 0 own spchmnisation j&gg nnniber 200. When the recpesting entity receives this packet 

it relnms a litrther paeket P30 once ag^in identifying the source and destination ports, 
and a flag indicating that its acknowledgement status is on* with m acknowledgement 



mumher 201 (Le, which mgmmis the sequence number by om)* Onm: iimmchm^ is 
mmplm, & mmmtkm between the client and server entitle is 4^$n^mM.ngope% 



0pm between them. In connection with the socket, if should also be noted that the 
socket comprises an area 460 allocated to store the body of ift§ message which it 
is 4§ sired to transmit {sometime known 

outgoing payload), and similarly a further area 470 allocated to store the body of 
Messages which are received (Mx^miinessag^ content, or incoming payfoad). 

When the outgoing payioad is to be transmitted, the TCP layer breaks it up Into 
packets (ie. data structes such as those illustraW above k Fig, .3, hid further 
including at least part of the payioadh and the IF layer attaches an IF address header. 
When an Incoming Biessage arrives, it passes up through the network slack, i.e. from 
the network card 3 40, up through the Internet Protocol software, etc,, and is written in 
to the relevant socket (as identified, inter aha from the port Humfeer), from which the 
application program retrieves the incoming payioad. 



Data may alternatively b^^ RSTP/UBP/I? (indicating 

the hierarchy of protocols m the network stack adopted conjunction with each other 
to transmit the data) which do »t require a connection; the dispatching entity seMs a 
packet to the destination entity, and does not require an acknowiedgemenl of receipt. 

Referring now to Fig. 4, when transmitting data in accordance with RTSP/IJBP, media 
for example is streamed to a client entity 10 from a media server 20 in a series of 
packets PlOO, F120, PI20. , and the client does not aelmnwledge receipt of any of 
t&em. Streaming in accordance wife this protocol typically follows an initial request to 
establish a conneetion between die client and the scsver by some odier connection 
based pTDtocoI, fer the purpose of identifying a destination port m the client, amongst 
other things. 
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fhm far all tot has been described w mimly mm&ntixm&l BM erring bow to Fig. S, 
in accordance with a first embodiment of the present Invention* a layer -of viral 
§ mp$%0m mmnim^ (VPMS) St%ruB^w simk of one or 

mote machmes within t&e network The VFMS acts as a gateway for all oiitbosad. data 
5 &om tf«? computing entity an wfiich it kmmhi^. m^ptmms tB tm^m the 

propagation of viruses within the network by observing what is* in accordance with a 
pred eteraimed pof icy* defined as "imusuaF belmviotsf in contacting otter entities (also 
known as <: %q&$>% mm® ikefni&y act as hosts for viral feffecfen) mihm the network., 
I! has heen extahlbhed by the present inventors that in many networks, normal network 

1 0 telle (m. non~ vimf ly relMed) is characterised by a relatively low fre<peney of events 
in which data is sent to destination hosts (Le hosts which are the intended destination 
for data) within the network which have previously not been contacted* In contrast 
vlrally-related traffic is often characterised by a relatively high frequency events in 
which data is dispatched (or attempts are made to dispatch data) to previously 

is uneootaeted destination hosts, Broadly speaking, the fenetion of the VFMS is to 
moni tor abnormal and therefore possibly virally-related traISc, as doted in 
aeccmiance with a predctermiried policy, and to record s^eh abnormal traffic, 

te the present: example the VFMS operates upon the basis of a seri es of time intervals 
2:8 or time windows, which in the present illustrated example are of predetermiBed am! 
constant length I* In any given time window T R the VFMS monitors requests to send 
data to * x new*' destination hosts, i.e. destination hosts whose identities differ from those 
specified in a record of klemi ties of destination hosts most recently contacted, The 
record only holds a predetermined nimbet M of destination host identities, so that a 
25 destination: host is classified as new if it k not on e of the N most recently contacted 
destination hosts, lie number of now hosts allowed per time window, and the value 
of N ans detemiined on the foa^is of the policy, typically defined by a system 
adtB Wstrator, and the policy is pn?ferab!y fpmmlalM to take aesoimt of the natum of 
non vitally-related network traffic, M this way , the VFMS operates to monitor the 
3 0 speed at which a vims resident on the host may propagate from that host to other hosts 
within the network 
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Referring to Fig, 6A ; over the course of a time window Tl , vadons applications 
fmgramsM^ send requests via the VPMS to smci data 

(whether by connection or otherwise) to other hosts within the network C^thorf 
request): the email application pi^gtaa% w email. 
5 mess^go (baling mtdtJple addressees) to a mail server, Mail (Ee<pe$t A), using SMTF ? 
the Sle marisgernen! applics&n program recpssting dispatch of a tile recording a text 
document to another user (Eequest B) vi a FTP, and the web- hrowser^ 
roosts €Oi^i^tf<>% (t>pieally via a Web Proxy, server), . l(Sm« m 0? ip mmmi 
to a site using HTTP (Request Ch In the present example, oulhoi^i requests to the 
10 YFM8 ifem each of these hosts axe repests to send data to m identified destination 
host, md are ult inMely femife^i by fee dispatch of one or more data packets m 
wxmmmm with the relevant appMoaiioM protocol. The temi "reipost'^is feteoded to 
he felerpretci broadly to encompass any indication (usually from an application 
program, although fey 00 means necessarily) that contact with a destination host is 

1 B sought* am! for ease of te^ reqwst is to he interpreted 

as indicating that data is trmisnii Ited pursuant to a request to transmit snoh data. 

The VPM8 operates in accordance with a rou&ne iltoslrated in fig. 1; whose features 
will no w he described in more detail in conjunction with Figs;6ArC, although fig> 7 

2 0 should be regarded as a generic illustration of the operation of the VPMS routine, 

ratter than a specific iliustra^on of individual e vents depicted in Figs. 6. As explained 
above; the VFMS operates with relerenec to a scries of time intervals, or windows, 
which in the present example are of constant length. The routine is initiated at step 
702 by a clock (typkaliy the clock which defines the time windows) indicating that a 

as time window has eornmer&ecL At step 704 the routine then updates ;a;dispatch..i^^ 
whi&h is a record of the identifes of a predetermined number M (which in this example 
is 3) of de stination hosts most rec ent ly omtaeted (in accordance with the policy ~ see 
later) In the previous time window are stored (a^d : whi?fe. are shown, for each time 
window in Fig, $B% At this point the routine is effectively in a wuiting mode until a 

30 ^n^to.iemf data is received at step 70S (a dotted ..arrow fmm step 704 indicating 
that receipt of request oeenrs temporarily ailer step 704 hut is not consequential to its 
oecuiience^ This is & step whose oecnrra*ee is entirely outside the control of the 



VPMS sinceit usually is initiated at fee behest of M applkm« program, .as is ths 
ease with &eqxm$U. A* B and C; Bach of %se r^ilests passes through the relevant 
application protocol layer in the network stack from Uie respective ^plkatlon program 
% which they were generated, to fee 'YPRSS, and this event is labelled in Pig, 7 as step 
706. Step 706 m ay he thought o f as a inggering evenly so that when a request passes 
into the VPMS, fee ideMily offe mpestol destination test specified in the request is 
matched with fee dispatch record. This matching process therefore determines 
whether the nequestedd^^ a «w host, and is represented at step 70S, In 

the present example, somewhat -aitifieialiy, feat nonetheless serving to illustrate fee 
desired pn nciple% the ti me internal T 1 is the irst time interval ate start-op o f the 
computing entity. The VPMS therefore matches fee destination host Menmies for each 
offeele^^ identities held in a dispatch reeori 610 fer fee 

time period Tl . which may be (ani in the illustrated e&ampie, is) simply a record of 
fee three hosts most frequently contacted during the lifetime of the host on which the 
VPMS is monmg. fa the present example the feree most frequently contacted hosts, 
and therefore the feree identities retained in the default dispatch record are those of the 
mail sot (Request A), the Hie server (Request B) and the weh proxy server (Request 
C), Since each of the three outbound requests torn the workstation during fee time 
period Tl identify a destination host matching one of the three host identities In fee 
default dispatch record, and there&re none of the Requests is seeking to est A &h 
contact with a new destination host, the VPMS therefore? takes no action and simply 
ends at step 7 111 

During fee course of the second time interval T2, ihi^e teher onfeou^d requests are 
received, identifying host destinations ^fatoel Peer r (Request D}> Request B 
(desmhed above) aad 'Intmuei Peer 2 s ' (Request E) are received. As in the previous 
time window, as each request triggers ^ individual V PMS routine for that request, he, 
a step f 06 as it passes through the VPMS, and is -followed by the step 708 of matching 
the identity of fee host destination m the request with the identities present in the 
dispatch record 61 2 for M$ time window 12 is performed in order fe estahii sh whether 
the recast is new, The disp&fch record howe ver is now a genuine record of fee 
identities of fee three hosts contacted most xesenily during fee previous., time window 
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"T I (although caiBCidet^ally this & .'identical- to ih& default dispatch record) > Upon 
receipt of Request pj the consequently triggered VFMS routine for tfcat request 
^tablsshes at step 70S that the identity of Ibis host is not in the dispatch record 612* le. 
feat it-is a «w dest mMkm host. It therefore proceeds to step 7 I 2y where it adds g copy 
5 of the Request 0 as an entry to ^. virjwaa. l^ifBear -«4iosisS: cspntent^ ; : sfipp : 4s3ap««t .-iaa "I^g* 
and then ends at 71 G. In one |?refeiT# einbodimai^ tkt, entire contents of the socket 
relating to R&psst D are duplicated to form the entry in the virtual buffer However in 
ail alternative emhodlinent, where for example the payload is large, this is omitted. On 
reedpt of Request B, the VFMS establishes at a step 708 that B is present the 
18 dispatch record, and so the VFMS routine ends at step 710. Request E is also a new 
request within the time window T2 and so at a step 712 the identity of host E Is added 
to tl^ virtual boiler. 



Because receipt of requests are the trigger for the commencement of the routine 

I S ilteteted m Fig, 7, neither the number of occasions in a given time window in which 
the VFMS routine is run, nor the tinting of their commencement can he known m 
advance, AdclMonaliy, as iifestmted in Fig, 7, i t is fmmbW for two (or indeed more* 
although only two are illustrated in. Fig. 7 ) routines to he running in temporal overlap, 
since one may still he rusming when another is triggered by a ferther request, 

3 0 Similarly, a request may trigger the e&eention of the routine of Fig, 7 just prior to the 
end of a time wimfow (a situation also iltestrated m Fig, 7, with steps which occur at 
the end of a time window/the hegimiing of a subsequen t time window being sho wn in 
dashed lines), so that the execution of the routine may overlap temporally with a part 
of the next time window, lie approach taken by this par&ukr embodiment to this 

25 issue of overiap is relatively simple: if at the commencement of fee wimiow T^,. , the 
update of the dispatch record fpr a pre vious time window T» has been completed 
during the si nmlta^eous running of a VFMS touttee <x>mtne^eed in ite previous time 
window but prior to execution the step 712 (adding a inquest to the virtual butler) 
for that rontfoe, the snbseqaeM update of the virtual buffo in that mf 712 will be 

3 0 treated as if p^rfoiMed ibr a request received in the eii&eftt time wtBdow , This 
approach has the beneit of being simple, although it may on occas ions yi eld m i nor 
inaccuracies* with a lequest being recorded as bei ng outsi de of the policy simply 
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because processing of the request recei ved and initially processed during one time 
waow extended into the next time window, but this k nonsignificant overall 

At the end of the time window 72, the virtual bufler contains two new requests. At 
s ihm j uneture (l e> at end of time period T2) ? the policy which the V PMS is deigned to 
monitor comes into pl^j, In t he present example the policy provides that a single new 
host may be contacted per time interval This element oftfta policy -is monitored by a 
first bufe* M^agoment roMim, whieh h iOuslrated ^epMically m flowehart form m 
Fig. 8A ? m\i\ begins at step 862 with the advent of a dock timeout, that kto say tfe&t 

10 the clock (not shown) wMch deOBes te time intervals T^ has completed another time 
period, following which, at step 80.3 the routine counts the snmtfoer of requests in the 
virtualhuffer to update the variable known as LogNo> this being the number of mines 
f each identifying a request) in the virtual buffer at any moment. At step 804 the 
routine detennines whether there are any envies in the virtual buffor* and it does this 

IS by examinrng the value of Loghte, to detemilne whether it's greater than 0, If there are 
no entries in the virtual bn& at step 806, In the present illustrated 

example however it can he seen that over the conrse of the time interval T2 entries for 
two requests, D and E have accumulated in the virtual buffer, and so the routine 
proceeds to step 808, at which the entry for the first request RQ1 |te* the one which 

2 0 has been in the buffer for the longest time) is deleted torn the ho fe\ Optionally, at 

step 81 0* the routine then searches the buffer for other entries speei lying the same 
destination host and deletes any such entries, since they are effectively regarded as one 
entry identi ty. Alternatively, step 810 can he omitted. This k followed at step 812 by 
updating the dispa&h record so that it accnrntely reflects the identity of the three hosts 
as most recently contacted in accordance with policy* It should be noted that the dispatch 
record does not therefore necessarily nefieet the identities of hosts which have most 
s^entiy actually. bm\ e^mtaeted,. if requests to t hese hosts are outside of the po hey. 
•For example in this case the destination host of Rmfuest E, wMoh although eont^eted y 
was not eon&eted in aocordanee wi& the policy of one new destination host per tlrn£ 

3 & : interval This updating of the dispatch record can be seen reSeeted in Fig. 6B> where 

the dispatch record eontalns the identities of Requests €, B* The final step in the 
first buffer management routine Is the updating of the value of the variable I^gNo 
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.denoting the sfee of ike yirtiml buffer, which lathis exsmiplfc, following the 
ir^Missfon of the Request IX i s one (i.e. the single Efeqtiesi BX Thus, in present 
embodiment in the same way that the dispatch record is a record of recent requests 
which have beep transmitted in aeconknee with policy, at fee of each lime teterval 
the virtual buffer is effectively a record at any instant of requests which have been 
transmitted outside tMt poIiey, 

Qm role of the virtual buffer is to p&hle a deteoninatian to he made with regard to 



which this can he manifested is the size of the virtual, buffer. A state of viral infection 
may therefore he defined in terms of the shse of fee buftr v and the stage of an y such 
viral infection hy the rate nf change of the buffer sfes. This follows from the generally 
different behaviour of\#a%^eIated and uon viraUy-related network traffic, M that 
mm ViraHy-rekted or 'legitimate** network traffic usually involves coutaeting only a 
relatively small number of new destination hosts, whereas, because viruses tend to 
propagate hy transmission to m many disparate destination hosts as possible, an 
instance of a large number of requests to contact a new destination host will typically 
be indicative of viral infection. The virtual buffer may be thought of as a queue of 
virtual new reqnests waiting for opportunities to he virtually tosniifted in accordance 
with policy (since their ^oumerparT real requests are simply transmitted without 
hindrance). The size of the virtual huiler is themfere one indication of whether there is 
viralinfeetio^ since a large buffer size is indicative of a large number of requests to 
contact a new host within a short space of time. An alternative indication of viral 



indicati ve of a temporary increase in legitimate traffic le vels It can he seen therefore 
feat buffer size may be used to interpret the existence of viral infection with varying 
levels of complexity* tie interpretation typically being sornetliing which is defined in 
thepo&y. 



and is triggered by |>erfem^ice stop 814 feni the routine of Fig. 8A ? or fern step 




which the V PMS is running is virally infected One way i 




A $mond bnf&r manapment rontine, illnstrated in Fig. SB monitors thevirtaa! buffer, 



IS 



803, or from step 71.2 in Fig, 7 i& $ii update in the value of the variable l^gblo* 
Following which, at dedslon step 142, the route defemim^ wh^th^r the mm of the 
kife is greater than a quMtiiy ¥ v > which the policy has detennked represents viral 
rnfedio^ whereupon at step M4 it generates a virus ajtafc IMs mm mmply b^ a visual 
5 alert to a user of the workstation 1 % or a message to the network admin* strator , or 
both, or even a trigger for automated set ion to shut the network down, as desired. At 
step §46, &m routine determines whether tho variable V, is inciting above a gi ven 

kid if It Is, issues a fbrfe warning indicating the o^set of viral infetion at step 
848, following which the tmifke ends, 

10 

A skuahou hi which the second hu&nt^^ infection 
warning can be seen in Figs. 6A»€, As mentioned previously, during time interval 1% 
a single Request A (which it will be recalled from the time interval Tl is to contact the 
mail server), and two Recinests C are received. Because the di spatch record 614 for 

is this time interval does not contain Request A s it adds the identity of host A to the 
virtual huffe; hit not the ideutily of host €, At the end of the time interval T3 the 
virtual buffer therefore contains Request E (stored in the virtual buffer since time 
interval T2) and Request A, Since only one new request 1$ transmitted per time 
window in accordance with policy, and since Request B has been in the virtnal buffer 

20 since time interval T2> whereas Request A has just been added. Request E is deleted 
fern the virtual buffer (a process with may he thought of as "virtnal traasnusskm**), so 
that at the start of time interval T4 the virtual buffer contains only Request A, This 
indicates that at this point in time, since startup of the entity on which tire VPMS h 
running, only one more request has been transmitted than the policy allows. The first 

2 5 Request fer cormection in time interval 14 k Request B, which i Ilustrates that over the 
C0urse of three lime intervals, during which only norma! network traffic has beeu 
transmitted, eonnec&n has. only been requested to five different destination to 
However, Request B is nonetheless defined as new because it's not in the dispatch 
record 616 for time interval % and so the identity of ho^t B is steed in &e virtual 

30 buffer (this action feeing illustmted at the same point in the timeline in Fig, CSC). After 
receipt of request B , two groups of five vktM% siMiiltpieous: requests m^rmmM^ F- 
if > md ,&>O s am! since these axe also new, their identities: are also a<Ided to the virtual 
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fonfe. Reiemng Sf^ifkmll)? to Fig. during time iMemtl i% it em readily he mm 
that -virUM h^^MB^t^B^^m. a mm of one ? to l&'m$ m mmr&mm with 
the policy Ms m4%fim& m vim! mfectioti, since m the p resent example a bufler ske 
of greater than Tim generates this alert. Moreover, since the rate of change is positive 
5 md rapid (from 1 to 12 in. a single time interval), this Is indic^ti ve of the oiisot of 
infect ion. Thus the likelihood is that a substantia! nmhher of the requests transmftg^ 
during theeoiiTse of time internal T4. have been virahy related 

In the avast that a viral warning Is genemte^, various further actions mm then be 
i d i&ke% : the m^ority of which are directed toward finding out more >MM the nature of 
any possible virus. Sped&ally the type of hifonn&tion sought may typically hie Jude: 
the iestlnatfens to which a vims has been propagated, where applicable the application 
program or programs which It uses to propagate itself and the action and behaviour of 
the vims. The nature of the kfomiMioB which may obtained directly fknn the virtual 
IB buffer, or which may he deduced therelrom depends to an extent upon the nature of the 
data stored In the virtual buffer, and the op^ralirig system of the host concerned. For 
example in the c ase of one p^ 

copies the aocfeet, inekdiug payload, the destination host will he recorded in the 
huffe and p0ssibly/mlhc ease where the virus copies itself to the socket as the 

20 outgoing payload, also the vims. Additionally, where the operating system records an 
identiSer i?) the socket denoting the apphcation program reque^tmg the socket, md an 
ahDity to map ihm process identifier to the requesting application program aSer the 
socke t has been closed (remembering thai the virtual ha IEt coptates a copy of the 
socket, while the actual socketis tosient sitiae it is used to implement the request to 

25 send data and is then deleted}, then the application program responsible for requesting 
data transmission can he identified. The use of the data in a socket is only one way in 
which to collect data relating to possible viral infection, md when using sockets, 
depending upon the extent o f the data collected, the reliability of copying of the 
sockets is hfcely to vary, For example, ill as referenced ahove, the Mlmi data 

30 (ioclndmg c>g< copies of the payload) is to he retame^ ferther copies of the sockets in 
the vktoa! hnfler (stored for exampl e in a manner which tags them to the copy of the 
socket in the virtual buffir} are preferably made over time as the contents of the socket 
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changes over time, However, because two fictional dements within the host may 
cause a change in % data m a socket (e,g, the writing of outgoing data to & sockel by 
an application program, m& removal fmm the socket of omg^mg data by the netwwk 
stack), maintaining a complete record may nevertheless still be difficult snnply irom 
5 observing the contents of sockets. 

'him, alternative embodiment the network stack additionally meliides a layer 502 
(illustrated in fig, 5), known as a packet logger, known per m. According to one 
embodiment, when a viral warning is generated as a result of the virtual buffer mm 

io i^mmd buHbr ^ socket tiie 

logger 502 is switched on, and makes copies of outgoing packets. These may be all 
ongoing packet^ or packets identified by one or more partioniar destination IF 
address, the identity of which may for example be established Item the copies of the 
sockets in the virtual buffer. By logging packets eornplete information may he stored 

IS relatively easily, since, for example even in the ease of large payloads, the iMi vidnal 
packets eanying various parts of the pay load may easily be aggregated using the SBQ 
and ACKmxwhm, Further, if desired, the use of die logger enables incoming packets 
from designated IP addresses to be logged, which may provide valnabfe klhmiatiou in 
eire^mstanees for example where a virus has a "hand-shake" action with another host 

20 (La, s^ds back a packet to its originating host torn a distillation host) m part of its 
propagation process (as is the case, Ibr e&aBiple with the Ninida worm). 

He relatively early provision of warning of viral infection is poteniially extremely 
beneficial, since in the ease of many virases the rate at which they can establish 

25 infection accelerates over time. For example, in the ease of the code red vims, it has 
fen established that over the corn^c of the first !(> hours, lOJKK) hosts were infected, 
but thai in the mahseqnent 8 hoors the virus infected a further 340 5 0flfi hosts. Jhe early 
collection of data on viral infection can thus enable actian to fee taken, cither within the 
hosts within which infection has been detected, and/or widiin other hosts, which can 

3 0 substantially reduce the extent of subsequent iniection. 
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In fee scenario IHiistMed in cmmxtion with Fig, 4. & single outfeoBml. reqnes* 
(Request A) to fee VPMS> specif^ng a xmgk destfe^tion host, oauielv fee mail server, 
dually eonMm a plurality of emdlB^^5igex to different specified addressees. This 
outbound requesl may therefes-e fee thought of m a carrier Truest lor a plurality of sub- 
s requests, here fearing the form of putative email phages intmded tor dispatch .from 
the mail server to a list of addressees specifi ed within the onftonnd earner request 
(simllariy, the mas J server may fee thought of as acling as a pm y destination host for 
the ultimate addressees specified in the outbound carri er reqnesi), & this avtoatto% 
ailow^ o f the data packet eoBsiitutteg the message to the mail server 

10 will fe fact effectively allow the workstation to contact multiple other hosts within & 
network (Le, the specified addressees) all of which may he new, even though, in 
accordance widitheTomkedeserihed in connection with Fig, 7» the onthmmd carrier 
request will only count as a single re<|iie$:rwhieh may not even he recognised as new 
if, a$ may be likely, the mail server is identified in the current dispatch record, In such 

IS a situation therefore, if the VPMS operates simply to record in the virtual buffer those 
Bew destiuatioii hosts to be contacted per time window on the basis only of those 
destination hosts which are ostensibly identified In the onihonnd request, the desired 
monitoring of viml propagation may he dteumvented or reduced, because a single 
outhoBiid request speeifying the mail server does not necessarily represent only a 

20 single email subse<pentfy the neiwork after processing and 

forwarding by the mail server, 

In a modification of the emtediment thus fer described therefere, the VPMS includes 
within its routine a step of identifying the application program fey which an outbound 

2.5 request has heeo generated. Because certain applications pmgrams are more likely 
than others io nm outboinid ^rn$r. r^quest^. winch invoke: the use of a proxy (&r 
e&ample fee ahov'^mentbned. ImtM^e- of ^rnaii, or the case of a web browser 
program) it is possible in advance to speei% eriterfa, hased on tbe provenance of an 
oat bonnd reqnesL identi^iBg those onthouM requests likely to be caixier requests. If 

3 o the pmkm is generated by one such specified application program, then the VPMS 
invokes the use of the application protocol concerned to reveal die identi ties of the 
destination hosts speeified in the ^h-reqn^sts; here tbe eventual addressees for whom 
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the email message is inteMed, Once the identities of the genome at xMm&U 
addressees have been obtained* there are several options for pressing the request In 
aecorclaBC^ with om alt^maiiye the ides#teroftf^^^ specified m the 

suh-reguest .^bt.regakted m mmz&mm with ihs? same policy wMoh applies to all 
5 other requests, and feey can fee matched against the host idei)tkies wlfein the dispatch 
record in the manner previously described in the embodiment described in the above in 
Figs 6 ~ S> Further was in which m^lhple-addressee email messages may be handled 
to cliseussed beiow. 

io Since m the case for example of email, the use of outboxind carder requests to a host 
aotingas a poxy for the ultimate add^ssees of the email messages is the none, it is, in 
a modi fication, possible for ditTkmt versions of VPMS to mn simutaeousiy, 
elfetively operating m parallel with each other; one which applies: to hosts specified 
hi the onthound request (including earner requests), and another which applies to hosts 

i s spcifkd in ^ application program, to such a 

situation, each VFMS will operate independently on a category of requests w hich it is 
intended to process, using its own dispatch record, and implementing a policy for 
onthound requests tailored to the traflfc it is set up to control, for exam|5!e hv tbe 
mamer previousiy described and illuslraied in connection with Figs, 6 and ?> The two 

20 policies may be the sam^ (e.g, a dispatch record of 3 MenMies, a time window of 

constant duration T ISs and one .new host per outbound requeis^sub-ieqnest), or different 
asdesix^L 

The ebolee of the length of the time window, the nnmher ofidenhties retained In a 
2$ dispatch record, m\d the number of new hosts to be allowed per time window are all 
dependent upon the likely i4 normtf network within which the 

VPMS is operaiing, and more :partiadrfy >;: ihe. nature of the network ira-ffic4h.e VFMS 
is intended to control Therefore, while a policy sueh as that illustrated in connection 
with Figs, 6 and 7 rnay be elleetive in m through 
3:0 &e network to a rate of m feetion of one new host per time interval, it m ay also he 
susceptible to false warnings caused by non virally-relEted, or ^legitimate" network 
traffic whose characteristic behaviour difes substantially {mm the policy the VFMS 
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is iaptementiBg, To ameliorate this d£M^uIt> s it : is possible to pwvi<k a wsion <>f 
¥MPS: f<>r each application p#grMi . fete wimh wiwmk traffic; mimmm with each 
WMS impkmenti?^g a policy tailored specifically to minimise thectece of false 
warnings with legitimate network traffic, Alternatively, m accordance wife a further 
5 preferred ^ is provided in respect of each application 

protocol which the feosti^g CEtity snpport^ and requests are routed to appropriate 
VFMS on the basis of the port identifiM in outgoing reqneste fe>m application 
softwares 

IP In a further embodiment the establistoeni of a record indicative of the norma! traffic 
destination hosts, may he employed to restrict the prc^&gMra of woses within a 
network, m example of which will now be described below with Mermee; Figures t 
to 14, 

is Referring now to Fig, 9, a network, which ,m previously mciudes a plurality of 
interconnected hosts; a workstation 910 which Is typically a personal computer lor 
example, a mail server 9! 2 f%IaiF) which handles email convocation within the 
network, a file server 914 fT/Servef 1 on which shared data within the network is 
stored, and a weh proxy server 916 via which any communication between any ho^t 

20 within &m intranet and an external host passes. In addition the network includes 
inther hosts not llkstrated explicitly in Fig, % one of which 918 is illustrated nnder 
the denomMadon A> R OTHER, and whose tendon within the network has no 
hearing upon tte ilkstraSon of the present emfeodiment. 

the workstation 9! 0 runs a pl urality of Application soltwan^ programs concurrently; 
2-5 and as described in conBection with Fig 5, m operating system software and usual 

hardware of the workstation, sneh as memory 920, storage 922, with an Ethernet can! 

Examples of the sort of applic ations pr^gnnns which run m the workstation 91 8 

include programs to baralte the receipt and dispatch of e:mM| ftii fhe .:m^il;^rvef • 9 1 2 :> . 

•a wah browsing program , a file manager progr&m enabling the organisation and 
3 0 asportation of files, and instant messaging software enabling the dispatch and 

receipt of ASCII tmx messages dircofly to and &>ni peers within the network . In 

addition, and in aceordsnoe with the illustrated embodiment, a further software 



21 



|m>gmm (VAP% .run$ within the network stack, in 

tie same position m the VPMS in Fig 5 adjacent the naiworkmg software 

As wife ihe VPMS the VAPS handles all requests to send outbound data from fee 
workstation 910, and operates to restrict the^ 

by limiting the extent to wMefe the workstation can engage k wlmt may he thought of 
as ^mmsuar behaviour in contacting other hosts. As motioned previously & 
connection with the V PMS, it has been established feat in many networks, nomsal 
network tmffic (i.e. non-vkalty related) is characterised by a relatively low rate of 
collection to hosts within the network which have previously not been contacted. M 
contrast vi rally-related traffic is fecpently characterised by a relatively high rate of 
connection or atteptod coinieetion to prevb^siy uneontaefed hosts. Broadly 
spealcfeg v tho feeiion ofthe V&PS is to i mpede virMIy-rekied txaffie, while allowing 
o»viraiiy related tmfle io flow with little or no impediment. In fee present example 
the VAPS operates upon the basis of a series of time intervals or tte windows, which 
in the present illustrated example are of predetemiined and constant length I* in any 
givw time window Tn the VAPS operates to preve^it the host upon which it is running 
fern transmitting requests to mo^ than a predetermined hosts, he, 

hosts wtese identihes differ from those specified in a dispatch record o f containing 
Identities of deslmaiioB hosts to whom requests ha^e recently been transmi tted The 
dispatch record obIv holds a predetermined nem so 
that a destination host specified in a rrest i s classified as new i f it is not o^e of the 
M fetination hosts to which a request has been transmitted. The n umber of new hosts 
allowed per time window, and the value of N are deteOTined on the basis of a policy, 
typically defined by a. system administrator and the policy is preferably formulated to 
take account of the natnm^ hi this way y &e 

VAPS operates to limit the speed at which a vims tesident on the host may propagate 
from that host to other hosts within the network. 

Referring to Fig> ISA, over the course of the time window II , varions applications 
programs running on the worfestato to the VAPS to connect and send 

data to destination hosts within the network; 
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rapists dispatch of an email message fliavlng multiple addressees) to the mail server 
912, Mail (R^wst A), the file i^aget^ 

M a file to thp Tilt server 9 ! 4 5 F/Sewsr in order to save a text document on a shared 
network drive pequesf B); m& Iht web browser program which requests contact with 
B the W eh Proxy server 916, W/Server in order iq contact ;a site sterna! to the sublet 
within which the workstation 9 10 Is located (Request G). as described above, requests 
to the ¥ APS from each .of these hosts may fee m fenn of requests to establish a 
connection to avidentilied destinMioa host, or requests for nse of connection all 
protocols and m previously, the term ""request is Intended to be interpreted in fee 
10 bmad sirjce indicated above to encompass any Indication that comaci with m identified 
destination host is re<| mred,, A t ec|uest &r connection, if allowed, is ibltewed by data 
typically in the ferm of data packets &om the relevant application program transmitted 
to the Mentlfied destination host. 



I B Ttese requests are processed in accordance with in incoming request routine, ibmihig 
pan of the VAPS (illustrated In Fig. 11), and the vartans steps that take place dining 
fee course of this routine will now he described In more detail with reference to the 
graphical representations of Pigs. 10A-D in combination with the flowchart of Fig. 11, 
Snbseqaent to their generadon by their respective appifeation^ pmpams, each of the 

20 outbound requests, heresnater ahhre vlated as Requests A> B> C passes from the 
respective application by which they were generated, to the V APS in the network 
stack, whereupon the process wiihk the YAPS which processes the requests is 
initiated in step i|Q2, XFpon passing into the VAFS, the identity of the requested 
destination, host specified in each packet is matched with a dispatch record in which 

25 the identities of a predetennined .number N (which in this example is 3} of destination 
hosts most recently contacted in the previous time window are stored (and which are 
diow^ for each time window in Fig. I0B), in order to determine whether the requested 
destination host is a new host, as represen ted at step 1 1 04> In the present example as 
previoosfy y ^ serving to illustrate the principles 

30 underlying emhodimeiits of the pi^scnt invention, the time interval II is the first time 
interva! after statt-np of the workstation 910. Hie VAPS ther efere matches the 
destination host identities for each of die Requests A~C against identities held in a 



•%Mlf' dispaish recorl 1010 for fee tim^ period Tl> which maybe (and. Its the 
illustrated ex ample, is) : s imply a record of the three hosts most ik^aeutiy cMiaete4 
during the hfetime of the workstation. In the present example fee three mml 
fequetitly contacted hosts, and therefore the three identities t etamed defk^lt 
dispatch record are those of the mall server 9 1 2 (Request A% the file server 9 14 
(Request B) and the web proxy server 916 (Request C), Since each of fee three 
outbound reqnesis from the workstation during the time period T t Identify; a host 
destination matching one of fee three host id^tiMes in the defeidt dispaieh record, and 
ther^fere none of fee Requests is seeking to establish contact with a mw destination 
host, the VAPS transmit each request at step 1 106, and in the present example this 
means that it allows a connection wife each of these hosts to bo estahl ished. 
Transmission of the request is illiisfrated schematically on the graph of 1% 1 OD, 
which has the same time scale as Figs 1 0A-€ S meaning feat the temporal relatvoaship 
between events illustrated m each of these p^apl^ eao he readily appreciated. 

Daring fee course of the second time Interval T2> three ihtfeer outhoimd requests 
identifying hast destinations 'Intanei Peer $*■ (Request D)> Request B (which as 
indicated above corresponds to the File Server 91 4) and "Intranet Feet T (Request E) 
are received by the ¥ AFS fit>m: an instant messaging ai^heation pro-am (in the case 
of Requests D and Eh and the word processing application in the ease of Request B, 
As in the previous time window, as each request passes to the VAPS, and as 
previously indicated in step 1 1 04, fee identity of the host destination in the request is 
matched with the identities present in the dispatch record 1012. The dlspateh record 
however is now a genuine record of the identities of the ferae hosts to whom request 
km% b&m IrmmiM^.mmi ree^ntly.:in accordance with the policy during fee prions 
time window TI (although comeideotalfy this is identical to the default dispatch 
reeord}. Upon receipt of Request D, the Y APS estaMishesat step 1014 that the 
identi ty of this test is riot m the dispatch record , Le. that it is a new destination host, 
whereupon the request is denied, aid is instead stored in a delay buffer step i 108. The 
delay hufer is elfetiveiy a queue of requests which have; not heen tmnsnhtted, and the 
contents of fee delay buffers IOC (fee delay huffer 

Is shown M Bg> 10C on each occasion feat its eontonts change), ft therefore follows 
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that for %mh mqami iUusita&d in Fig, 10A, there is either a c<>rr#poMfeg change in 
the delay bailer (ill ustrated m Fig, I OC) when fee request Is denied or mmsinkdon of 
the mpssi (illptrated m F*g> tOD) when the request is transmitted (possibly 
accompanied by a change in the despatch record). Request B is processed as 
5 pre^o^^Iy indicated, and given that B Is present in the dispatch record, this request is 
traiisniitted.^. ^pkoan. h& seen in Fig. 1QD, while -'Request E ? in a similar maimer to 
thai of the msl&uee of feque&t D, is denied and added to the delay bullet, as illustrated 
in Fig. IDG, 

10 Thus, at the end of the time period T2» no requests to new destination hosts toe been 
traasmitted, and the delay bufler contains two entries. At this juncture (i.e. at end of 
time period T2} :> the policy which the V APS is designed to implement comes into play. 
In the present example, the policy provides iMt a single ne w host may he contacted per 
time interval This element of the policy is implemented by a first buffer management 

IS murine, which is iiltistated seheniatfcally in flowchart form in f ig, I2A, and hegms at 
step 1202 with the advent of & clock timeout that is to say that the clock (not shown) 
which defines fee time intervals IV, has completed another time period. At step 1 203 
the routine determines whether there are any entries in the delay buffer (identifyiag 
new requests), and it does tins using a variable known M logHo, which is the number 

so of entries in the delay hufler at any moment; if LogNo is not greater thau ! (step 

1204), i.e. then are m entries in the delay buffer the routine ends at step 1206, & the 
present iHustrated example however item he seen that o ver the course of the time 
interval 12 two requests, D and B have occurred, causing two eofresponding entries to 
mmmmlmm the hufe y and so the routine proceeds to step I2QS, at which the first 

2S request RQ1 jie, the one which has been in the buffer for the longest time) is 

tmusmitfed. Optionally, at step 1210, the routine thou searches the buffer for other 
entries identifying ra^ the sane destination host and transmits any 

such reqnests, the logie hehind this Being that, inihe event there is a vims in the first 
traiBmitted request RQ I , /farther copies of the virus are not likely to im deleterious to 

3 D any greater extent. Alternatively, step 1210 can be omitted. This is followed at step 
1 212 by updating the dispatch reeord m that it accurately retleets the identify of the 
ihmp. most recently contacted hosts, and m Fig, 1 0B it can he seen that the dispateh 
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recor d 'contains th$ identities 0, C, B ? which am fee tbree-most recently tTarismittecl 
requests, as indicated in Fig, 100 accordaiio^ with policy. The final step m the first 
buffer management roimne is the updating of the value of tbe variable iogNo denoting 
the sbe.of the teffer* wh&h m Ms mmxpk, ibl lowing the traismissiaE of the request 
S D, is one (Le< the single request E}« Tkte> at tbe end of the time feterva] the buffer 
provides ft:.recos(i: OtirT^quests. CKSCiariiisg. ouisMe ofthe feouuds of the policy* 

The buffer si^e plays m important role in Implementation by the VAPS of anofer 
aspect pf the policy, m that it is possible, if dedred, to define a state of mml infection 

X o m terms o f ^mmm of the buffer, ffid the stage of any sucb viral infection by the rate of 
change of the buffer stmt. This fellows from the generally different behaviour if 
virally-related and non vir&!ly«lated network traffic, in that nop vsrally-rektec| or 
'legitimate*' network traffic nsMliy Involves contacting only a relatively smalf number 
of new destination hosts, wlierea^ bec ause viruses tend to propagate by transmission 

IS to as. many disparate destination hosts &s possible, an Instance of a large number of 
requests to contact a new destination host will, iypkally: be imlkativ^ of : ^ml Mestk>B< 
Given that the buffer is effectively a queue of new requests waiting to be trar&mitted, 
the size of the buffer is one indication of whether there is viral inlcetion, sinee a large 
buffer size is indicative of a large number of requests to contact a now host within a 

a 0 short space of time. In addition,. If the buffer size is increasing, this is correspondingly 
fedfcati ve of tbo onset of viral infection, whereas a steadily decIMug feu!&# size, 
althou^i iargef will be indicative of the end of a viral infection. 

A second buffer management routine, illustrated In Fig, 12B implements this pari of 
2S the policy, aud k triggered at step .1 240 by the occurrence of an update of the value of 
(ibis being step 1214 in the first h&f ef This routine can 

also be triggered by step 1203, or step II 08 in Fig, IX Following which, at decision 
step 1 242* iie rontine determines whether the size of the buffe is greater thaa a 
quantity : Vj> wtdeb tbe policy feas determined represents viral infection, whereupon at 
3 0 step 1244 it gMterates a vims alert This may simply be a visna! alert to a oser of tb e 
workstation 810, or a message to the network admkistrator, or both, or mm ® trigger 
for automated action to shut the network down, as desired. At step 1246, tbe routine 



as 

detemmes whether the variable V* i s increasing above a given rate, md Hit is, issues a 
flutter warning indicating the onset of viral infeciiQa at step 1248, fblkjwirig wbich the 

5 A situation in whkh the se&ond frailer mana^ viral infection 

warning @sn be sem m Figs. lOA-B. During time interval T3, a .single Reqnegi A 
(which it will bo recalled from the fee interval Tt is i® ooniaci 3m jnail server), and 
two Keepers C are received. Because the di sp&tch record 1014 for this thne m terval 
does not contain Request A, this request k denied and sent to the delay b after, while 

10 tibo two Requests C are trafi^Itted. At the end of the tixne imerva! T3 ibe buffer 
therefore contains Request E (stored in the delay buffer since time imerv&l 72} md 
Request A, and in accordance with the policy, the Srsi buffer nianagemeiiiioii Ike 
transmits Request B at t he end of the time IntervaJ 13, meaning that at the start of time 
interval T4 the buffer contains only Request A, The first Request tor connection in 

is time feen^ Server), which illustrates that over the course of 

three time intervals, during which only normal network traffic has been transmitted, 
ejection has only been re^nesied to five different destination hosts. However 
Request B is nonetheless delned as new because it's not in the dispatch record 1816 
for time interval T4 f and so is sent to the buffer (this m^m W^gilk^plt^ at the 

,2 o same point in the timeline in Fig, li.C). After receipt of request B, two groups of five 
yirttfl%---^ are received: F4 y and K--0> and ain&e these are also 

lew, they are also added to the buffer npon receipt ami proeessmg. Refemng 
speeifieally to Fig. IOC during time interval T4, it can readily be seen that the 'butler 
has increased torn &m of one, to 12, mai h mmtimm with &e policy, this Is 

as defined as viral ini«tion 5 sfeee in the present example a buffet sl^e of greater than five 
generates this alert, Moreover, si^e the pte of change k positive mi rapid (fern 1 to 
.12 in a single time interval), this is indtoative of £be onset of infection. 

fetbe example described above the VAPS has been confignred to delay oatbonnd 
3 O respests, and as seen this has the ad vantage of being able to o se iie delay bnfe to 
provide nseful in&miation. M addition* delaying ontbourrf requests tor connection, is 
generally, regarded as being compatible with the operation of many compiler systems 
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MKimiworks* Howwer, ie VMS may b®. configured to operate M a number of ways, 
For example, in accordance with m atetati^ -whem fte. computer 

system perrmts, the VAPS may, Imymg denied the request for connection, and simply 
retam & suitable error message to the dispatching applicalion program by whkm the 
S packet was gepera^ Mvd then delete tfee pacfcei. In aeeotxlanee with this embodiment 
the dispatehing application program most, if Hie packet is eventually to be suoeessftdly 
dispatched then resend the packet fee VAPS< In tJiis ^itematiye embodiment, the 
policy relating to the number of how requests wMeli are to be IranMiitted per interval 
maybe implemented by initialising a v&nabie corresponding to the number of new 

W requests received in a particular time interval, and augmenting this variable whenever a 
.new request is received, Ileqoesis may then either be instantaneously transioitted (in 
the same manner as requests already in deleted on 

the basis of whether the variable indicative of the nnmber of new requests per time 
interval has reached a maximum set in accordance with the policy (Le, in the previous 

is exaniple, one), 

in the present example, the dispatch record lists iransmilted requests m historical order, 
with fee ordinal numbering signifying the temporal oMer in which the hosts where 
contacted, le< Mo> I indicating the host most recently contacted, and No. 3 indicating 

2 0 the host contacted the longest ti me previously (or "first in first 

mif. This is not essential, and it is espally possible to list the tmnsinitted requests in 
another orders such as "first in last out" for example, or 'least recently used"; 

In a similar way to that described in connection with the ikst embodiment, a single 
25 ouitamd request (Request A) to the YAPS, specifying a single destination host, 
pmfAy^-t^lmm f actually contains a ptorality of email messages to ditoent 
specified addressees, As previously, in such a situation therefore, if the YAPS 
operates simply to restrict the nomher of new destination hosts to fee contacted per time 
windo w on the basis only of those d estination hosts which are ostensibly identiSed in. 

3 0 the outbound request, fee desired restrictive effect mx virus propagation may be 

eirennwented or reduced, because a single outbound request specifying the mail server 
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does mi nm^mitympr^mtmlyu single m^ ^mqm^ |m%>agatlng tMMgh 
tli$ t^ and Idnv^fding by the mail s&v«t. 

As wife the fmi embodiment, m a modificatioB of the second embodim^t thus & 
5 desonb#,fhe VAPS includes withM step M iimMymgih^ application 

program by which an onihound request has been generated. Because certain 
applications progm^ likely than otherrto n^ 

which Invoke the me of a proxy (for example the above-mentioned iagaiee of eimil, 
or the ease of a web browser program) it is possible in advance to specify /criteria, 

i p based on the pro venance of an outbound tamest, identifying &ose onibound requests 
bkeiy to be carrier requests. If the packet is generated by one such specified 
application program v then the VAFS invokes the ase of the application program 
coneerned to reveal the identities of the destination hosts specified in the sub-requests; 
here the eventnal addressees for wl«n the email message is intended Once the 

t S Identities of (he genuine or ultimate addressees have been oh tailed, there are several 
options for processing the request, & accordance with one alternati ve the identities of 
fee destination hosts specified in the suh~reqnesi can he regulated in accordance with 
the same policy which applies to all other requests for connections, and fcy » be 
matched against the host identities within the dispatch record m the manner previously 

20 described in the embodiment of Fig. XL In the event that the message contains more 
new addressees than the polky which the VAPS is implementing will allow to he 
transmitted in a single time window, then what may he thought of as the surplus 
addressees may, depending upon the operation of the email propam, either be purged 
fan the list, and the message tmnsruitted (such snral us messages may alternatively fee 

2% dealt with in a different manner, which may also be spoiled in accordance with the 
poliey), or preferably they are stored in a delay buffer as illustrated in connection wife 
Figs, 10 and 11. 

Slpee/in. the ease lor example of email, the use of outfoonnd carrier requests to a host 
3 0 acting as a prosy for the iiliimate addressees of fee email messages is the norm, it is> in 
a niodifieation, possible for different versions of V&PS to mn simultaneously, 
effectively opiating in parallel with each oifer: one wtheh applies to hosts specified 
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m the outbound request (ii^Wmg earner .requ^ts^ and. :ano.te wMab applies to km 
specified m my mh-miumU- Meriiilled fey the email application program, In such a 
siMatlon, each VAPS will operate independently, using its own dispatch record, md 
mplmwniir$$ a policy for OBtboimd. requests tailored to the traile At is set up to 
5 control, for oxampte In ffe manner previously described md illustrated in mimtttim 
withFip, it) and ft The ^vopdlieiesma^ be ibe : sanie (^>g v a iiispatch r^rii of 3 
idMtitie%& time window of 0onstaBt d^iration md one new host per outbound 
T^quest/snb-req^est), or different as desired. 

1 0 The choice of the length of the time window, the: number of identities rets in a 
di spell record, and the number , of new hosts, to be allowed per time window are all 
dependant upon the likely ^nonnaP performance of the network within which the 
VAFS operating, and more p&riienlarly* the nature of the network traffic the YAPS 
is intended to control. T&ereiore* while a policy such as feat illustrated in comieetion 

1 S with Figs, 10 ami 1! may he ef&ctive in limiting the propaptioii of viruses through 

the network to a rate of iniectioii o f one new host per time interval, it may also he 
susceptible to interfering with non vlniily-related, or "legitimate" network traffic 
whose characteristic behaviour differs mihstaniiaily from the policy die VAPS is 
teplementing. To ameliorate this difficulty, it is possible to provide a version of 
20 V APS for each applieation program .from which network trafle emanates, with each 
knpkmmimg. a policy tailored spocM^ally to minimise the level of impedimem 
to legitimate network traffic. 

Referring no w to' Fig* 13 A, a plot of activity (le/the number of requests processed by 

2 S the V APS) against time is illustrated for example of fig. I Qk< From, this graph it can. 

he readily appreciated that prior to the vim! infection signified by the rapid increase in 
the number of requests during the time interval T4, only a relatively low niimber of 
requests are processed per time intervals and that therefore it is possible to use the 
YAPS to implement a policy prev^ to more than one new host per 

3 0 iistse Interval; witjiout impeding legitimate network traffic to any siginfieant ex tent. 

Consider however an except of a graph ilimtmtmg legitimate traffic How m Fig, 1 3B> 
where there are significant levels of acjtiyi^. fetei^persed. by % liiueh shorter period of 
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time dicing, which there k m activity at alt Applying ifee tBthet ^tmpI^ polk^y of 
permitting oonneetion to o&e "tie* test per lime interval* where all time inUrvdnm® of 
the same duration would si gmfkaitly impede the flow of the legitimate network traffic 
jllustrsfed in Fig. ! 3B> Ideally ther^lb^ m alternati ve po licy is r^ idred whteh 
5 accounts for fee nature of this legitimate traffic Sow. An example of such a polioy is 
lliiistmted referring bow to Fig. !3C> where two sorts of time interval are illustrated: 
S? 5 & relatively long lime interval, and a relatively short time interval Prom Fig, 
13C it Sai Be seen that when pia&M together atemately, the time iMervais § } 
corresponds to the time interval m the graph of the traffic How from Fig, !3B where 

id there m a flow of traffle, Md She time iMen f alS s to the tiiiie interval : between, two such 
time intervals, where there is bo traffic flow. By segmenting time for a VAPS using 
these two time intervals therefore, it is possible to eoustruet a policy which niatehes 
closely the legitimate beba¥iour illust^ted iii Fig, I SB, but still provides an 
impediment to the propagation of viruses. Such a policy for the VAPS may he 

is implementol using the variable LogNo, which as explained above eorrespotiis to the 
nusnher of requests present in the delay buffer at the end of any given time interval M 
the present exanipie it is desirable to implemont a policy which does not impede the 
free How of the legitimate traffic pattern illustrated in Fig, DC, and referring uow to 
Fig. 14, to this end a modified fet buffer management routine is provided. Following 

2 o a clock timeout at step 1402, the routine determines at step I #4 whether the LogNo is 
greater than a predetermined number, in this instanoe 10, this number being chosen, in 
cory unction with the number of request identities held hi the dispatch record* to be 
equal or slightly larger than the number of requests typically received during a "long" 
time interval St* If LogMo is greater &an tMs nuniber, then fee routine de&ults to slop 

2 S 1 408, where it transmits oniy the first request in the delay bulfe, md then proceeds to 

steps 1 41 2 to 1416 where Mentical requests are ixan^tnitted the record is updated, a^ 
the value of LogJfe is updated, If LogNo is less than I Ds, Le. less than 10 new requests 
have been reeeived during the eourse of that time intervBlv then the muiimpmm^M 
step 1406, at which it determines whether a ferther variable LogNoL-ast^. equal to the 

3 D number of ne w requests reeeived during the previous time interval, is greater than 

mm> If it % then the routine defeults onee again to step 1 408 where only a single 
request m transmitted from the delay buffer, If it is not, i.e. no new requests were 
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received during the previous time mterval, then the routine acts to transmit, at step 
141 0, requests 1 A 0 Wm ft* Way "bufSsr> followed: % the steps 141 2 to 14 16,. Thus, 
wheu 1 0 or less new requests are received during a time imervai, and no new re«|iiesfs 
were received during the previous time window, the routine operates to tmr&mii ait 10 
S requests. This nnniics the legitimate activity dsising a "feijg" lime iiiterval S& where 
the activity level is relatively high, but in the previous sliort time interval activity was 
zero. Correspondingly, in any time window where there were more than 1 0 new 
requests (i& a greater level of acti vity dian usual in a longer time interval) or where in 
the previous time window there were more than zm> new requests (which is the 
1 0 p&t&m of kgiiimate traffic flow illustrated in. Fig, 1 the tontine defaults to what 
may fee thought of as the "standard*" policy of one new request per time interval, thus 
:throttlin§ : activity di:flferi ng from mml legitimate activity, and which is likely to he 
vir&Ily-related * The modified routine thus implements a policy which conforms 
generally to the hehaviour pattern it tostrated m Fig. I3C 

is 

This modified policy implementation has been achieved using two time intervals of 
different iengtlis, ami a modified version of the hnfe management r online, effectively 
to .augment the number of destination hosts which, nltimalely (le, in this example, at 
the cud of time Intervals SO end up not being regarded as new. it h however possible 

20 to implement policies by varying other parameters, such as Che number of destination 
host Identities retained in the dispatch record, thereby increasing tor any given time 
it^erval, the imiufeer of destination hosts which will not be regaled as bemg new, and 
consequently iransmithBg a time interval (or in 

die ease of Fig. 1 3C and !4 > per alteo)ate titne Interval). This would be appropriate In 

25 cirouinstances where the legitimate traffic item of Fig, 1 3B was characterised fey 
contact with 10 destinatioxi hosts whose identities are the same, or »ilar eaeh time. 
To achieve tins for the traffic flow of Fig. 13B, two dispatch records for the destination 
heats are nscd: one for &e^ 10 destination host Identities, 

and the other for the time intervals containing no destination host identities* with 

3 o the two #§pafeh r§cord$ : being . u^. alfemately* However, as Indicated above, where 
the legitbnate traffic Sow is eharaeterised by contact with (in this example) 10 
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.#ilbmtt desiiiffation-'hosts ■ each tmi^ - ii%£«rvjai. % titsmadife^ 
app^ptiate hmmm it would still impede tins legitimate traffic flow. 

In y$l& te&er ami mor^ refimd verskm of thi^ policy implem^to^on v b which 
5 provision is made for contact with 1 0 new destmatidn hosts per time interval By a 
modified version of th&ronfee of Fig* 1 I> in which the further variables ISfeqNc, aad 
NreqNolast, denoting the muxiberof new req uests in a particular fee intOT ^, and the 
rmmfcer of new requests the preceding lime interval (and thus the real time equivalent 
to LogNo and I^gNolast) are used to transmit new requests eoMetnporaiie^us!^ up to 

1 o & :«sxbium of 10 per time inierva!, provided that the two criteria of steps 1404 and 

1406 axe satisfied, Le* that ReqKo m tern th&u ! Q< AMD EeqSolast was e^iial to zero. 
This modification has advantage of allowing requests to pass tamedialely, which 
m cases where legitimate traffic levels are Mgk prevents u^due impectiment to traffic 
flow, hi this modified version new reqnests which are not trmmmU^d are once again 
IS stored in the delay buffer, which as previously, inter aha enables an vindication of viral 
infection from the value of the i.©gMo variable. 

The operation of the V APS has been illustrated herein on a single workstation within a 
network. However, m order to be most advantageous it k desirably imp! emonted on a 

2 0 plurali ty of boat s m&m the sielworfc; the greater the number of hosts. u$on wh&h it is 

implemented resetting in a greater limit on the ability of viruses to propagate throngh 
the network, 

The use of a number of difeent VAFS tunning eoneiirrearfjv, wi th one V APS per 
25 application program is preferred, since it en&bfe the imf lementatiiui of diteent 
policies for iliffemi ^pplleatk>^. grogi^s and thus pohoies defied to minimise 
impediment to legitimate traffic Sow, while simultaneously providing protection 
against viral propagation via the ap|»priafed use of application programs. Other 
impl^neutations are possible, mieh m: a single VAPS implenientmg a single policy lor 
S 0 all applications pmgrams; a plwality of V APS, some of which deal with traffic fiom a 
specified appli cation program, and some of which deal w ith traffic to a partic ular 
destination port {which may be thought of gmerally as dealing with traffic using a 
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pastk^ or a -pluralify of VAPS may be provided mih 

each one dealing with traffic for a particular (i^stlnatioivport 

Tfee detection of viral activity cm fee determined m a rji^mte of manners. For 
s instance* it has beep described above that a vims is detected if the sise of Up delay 
buffer e&eeeds a predetermined value. However, it is possifefe lor viruses to operate in 
a marmerwMeh maintains a delay buffer at a large value* jmt less jfcaft the 
predctefHiiaed threshold used to indicate viml activity. Such viruses can be said to be 
■"Mm$ fee fesfeoid'-. Consequently, various offeer teclmiques may fee imi to detect 
10 viral activity, either as m alternative to the predetermined threshold sieo of fee delay 
buffer, or in combination with this or other techniques. 

For instance, a transient increase in the sizo ofthedday htitier may fee esed to provide 
an indication of viral activity. In other words, if the size of the delay buffer increase 
is (eg. the amount by which fee ske of the delay buffer increases in. a pedetemnned 

time) is greater than a predetermined threshold^ then it is regarded as indicative of vim! 
Infection. 

TMs can be measured m an insiantaneons vaf ue> or over a single time interval, or over 
S O a plurality of time Intervals, 

Alternatively, a vims may he regarded as aetive if there is a constant nou-zero value m 
the sise of the delay bnfler fer a pedeternimed time e.g; fe a predetennined number 
of time intervals. For Instance, a virus could he reganded as active if the sfee of the 

25 delay fenf&r is greater than a prMetermined value fer more than a predetemuned 

nmnfe &f time intervalSv This could correspond to a mrm. attempting to heat the virus 
detection or protection technique, fey riding fc threshold, Tim virus may fee providing 
a large number of requests to new hosts, hut with the virus attending to maintain the 
number of requests less than fee ahsolnie valne that wmdd irigfef an akniifbr 

3 o indicating viral activity, 
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■Mi additional parameter may be mirodwed: : itnto the above m^4mi^its^ to take into 
ae&dmtf situations m which m traffic has passed thm&gh the YPMS or the YAPS, 
This parameter Is termed the ""SsSteck*** M sbime cireimistaiic^ a host does not send 
quests fer a relatively teg time, and then .-suddenly wishes to $m4 a number of 
5 resists simnitaneonsIy> This eopkt lor imtai>ot% eprr^$pom! to a user returning from 
a lunch break, and then wanting to send a timber o f emai ls m&m browse aiiornber of 
we&ste on fee Internet, The slack parameter is suitable for accommodating such a 
situation mi operates to augment the .number of new req uests which rmy be 
l^ismiited and yet not stored in a virtual hiiife (the caseofVPMS), C3therwfee y if no 
10 traffic has passed through the monitoring system for a relatively long period of tim% 
&ma smh a burst of trafSc might fee regarded as indicating the presence of a virus by 
the VMS, Alte^ati veh; the VAPS might act to delay the new eopneetid^, 

Th^ vaine of the slacK parameter is determined based upon the number o f time periods 
1 S m which no bow traffic passes through the V APS or VFMS, There are two alternative* 
preferred implementaiioES of the slack parameter, The first implementation 
corresponds to no new requests being made to the VAPS or VPMS, the second 
corresponds to no new requests being despatched from the V APS or YPMS, 

20 In the first implementation the slack is Incremented for every predeteBMs^ed time 
interval or period in which there are no new requests (Le. no reef nests to a host not on 
the despatch reeordi M the second implementation of the slack variable, the slack is 
mereniented for every predetermined time to^ or period in which no new requests 
(w requests not identified in the dispatch record) are tnmsmitted, In both 

25 Iniplenientation^ the slack value is incremented np to some predetermined maximum 
valise f "feaslaefc^. 

The value of the slack parameter is decremented by each new reqnest that is allowed, 
preferably down to a minim um value (e,g, minsf aek ^ 0). If the slack value is at the 
3 o m«, then any hnther ne w requests are treated in the :iiarntai man» (e.g. as 
potentially Indicative of vim infection, or delayed). 



The slack parameter is thus very wmM m dealing with bursty traffic that k m average 
below tte normal operating rate of the network, but k »ef%ak>ve the limit 
CmsequeBti^ this parameter is useM m mmmng that the YAPS or VPMS does not 
mterfee with norma! deration belwiour of tbe network, 

5 

In a variation, a similar parameter* can he used for resiriefeg propagation of viruses 
viatn^Mpte-recipicM emails . 

Both YAPS and YFMS operate on the assumption that normal network traffic (e>g, 
10 emails) occurs at a low rate compared to Mtwork traffic instigated by a. virus. For 
emails seat to single reeipieMs iM$. is largely true - it takes lime to compose m email, 
and emails sent quieldy tend to be to addresses thai have been emailed recently; For 
instance, typical parameter val ues are a host record sise of % a clock time out Tn of 1 
minute, maxslack of L 

as 

Multiple recipient emails appear to the YAPS or VPM3 as /viruses, as they are 
effectively a large number of messages sent very quickly. Further, the addresses used 
on .multiple recipient emails are often fairly random, mi thus are unlikely to fail 
within the record of normal destinations. To achieve minimal impact on normal traffic 
20 would need a large dispatch record, and a large value for the slack parameter. 

Preferably, and as indicated abo^e m rnmmcim . wiik the :fecriptioii: of the VAfS> the 
record aid the slack are small otherwise the virus will be able to fetid messages to 
many recipients before being limited. 

26 As a solution to this. In addition to a eonveBtional YAPS/YPMS &r single recipient 
emails, a di liferent process is used fer multiple recipient mute. This uses a new 
pamnieter, termed feerek ■ ■ mSLACIC ■ f whieli has a. value of between mm and 
"ma^MSLACK' ' (Le> the maximum value oP*m$LACM?% The value of mSLACK is 
incremented period or hiiervai that th^ user does not send any emails 

3 o mails, up to the maximum mlm .of maxMSL AGK The value of mSiaek can be 
Incremented by elite of tfee methods described previously, In mm. em bodinient, the 
value of rnS t,AC3C Is reset (i.e. minced to rero) after evet^ mnltipte mall te fen 
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sent A typical valns Ibr maxMSLAGKL is 2$, A typical clock time out period (Ixi) to 
'utilise, is one minute which can be tkv&sms value of to time period used for siding 
emails to single recipients, & m alternative eimbodi^ 
decrementing lis v&te by an &tnom& eq&al to fee number of transmitted requests, 
s which in tti€ case of a multiple recipient is Use number of addresses to whom email 
has been sent 

A YAPS or WMS lor emails may be used oil a host maetene that semis ffee emails, or 
more preferably it is implemented on a mail server (for instance either a Microsoft 
10 Exchange Server or an SMTP server), or on an inpni to the server. PrelerEbly, a ¥APS 
or VBMS is intpfemented per email client e.g. pet host machine or per email user, 

^lornialij^ an email client will send a single multiple recipient email to & server. The 
server then generates a separate email (a copy of tfee multiple rceipient email) per 
l s recipient within the address field of the multiple recipient email, and then semis these 
copies to each recipient. 

If a VAPS or YPMS ntilising the parameter mSLACK is implemented on- a host 
maehme (e>§, the machine with the email client)* It is preferable that the email client 
20 {or the ¥APS or ¥FMS) is arranged to split every multiple recipient messages Mo a 
multiple number of single recipient emails. 

figure 15 shows a flow chart iilnstr^ing a VAPS inipleniented for email, and niihsing 
the parameter mSLACiC 

25 

Once an email km been generated by a nse^ a cheek is made as to whether the email is 
addressed to be sent to a single recipient* or to mnitiple recipients (step 15 1 0). If the 
email is to he sent to a single recipient &ert the email is proeessed hi the normal |§fcp 
1 530} with a check made as to whether the intended recipient is a recipient in the 
30 dispatch record. 
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If the email is. to be $mi to multiple m Jpi&its, then tfee value : of the. parameter 
mSLACK is deteqitmed {sipp 1512). The wine of inSLACK co^pomfe to tile 
number of time mteyafe that have passed since the user sent a preyioos nmftif k 
i^i$&®tmwl y there are two aftettiali^ 
5 parameter. 

la the first implementation the mSLACK is increment ec! for ever/ predetermined lime 
interval or period in which there are m xm^mm m^ received (14 no new not in &m 
despatch record - requests to send a multiple recipient e-mail). In the second 
1 0 impleme^tato, the ibSLACK variable is incremented &r every predetermined time 
Interval or period in which no request are twsinitied (up to the ma&teum value 

A check is then made as to whether or not the value of mS LACK & greyer than or 

1 % equal to the number of '■■recipients: of the multiple email (step 1514), If. the value of 

mSLACK is greater than or equal to the number of recipients, then the multiple 
recipient email is sent to all of the recipients (step 1 516). Ib the present embodiment 
the value of mSLACK reset to zero (step .1.5.2% however in aa alternative embodiment 
mSLACK is reduced by the number of recipients in the email 

20 

Option I : However, if the: .y&hie. of mSLACK • i& ie$s.tb&& 'the number of recipi ents, 
then a delay mechanism (step IS 1 8} is utilised , If the multiple recipient email is Being 
processed m m to be sent out as a multiple number of single recipient emails, then the 
first tnSLAC!£ of Qiese single recipient emails are dispatched, with the remainder of 

2 5 the recipient emails generated b£ing \%nms& oft * delay hnl&r. These emails Me 

then taken off the delay buffer at a predetermined rale (i.e. one per time period), his 
envisaged that the messages which may be split into single recipients^ and the multiple 
recipient mails can share the same delay bnfffer. 

30 Option 2: Alternati vely, if the mtiltipk incipient email is not being split I nto a multiple 
number of single recipient emai Is at this point (e.g, . if the . ¥ AP S is Impleniented within 
a host machine that sends a single miiltipie ? eoipiont email to an entail server!, then the 
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multiple recipient email m delayed. In other words, ih& hm % miil im® plmtd 
m it that is equivalent to the time that the last email would have been sei^t lf of »ob 1 
had been utilised 



S By utilising snch a parameter, small dispateh records ean. be utilised without unduly 
delaying multiple recipient emails, since the disp&lelh i^cords play no pan in the 
control of multiple-recipient email nressages. 



Typieaily, in all email impJemeptatiom, k will be desimble to implement two 
10 ibresfcoMs on the delay buffer to trigger other activities. When the buffer mm reaches 
a predetemiined first tteshoM, a warning is seat to the user of the email client. This 
warning may imtade an indfcaiiosi that the Bomber of request s s sent i$ high (a single 
email message to N reeipfent being treated as N requests, that tfee number of emails 
sent is mdkative of viral activity, arKl thai the outgoing emails may be stopped if 
is similar activity persists, 



the host are stopped. Preferably, 
user to he kept informed of events, 
20 email block. 



high threshold, then outgoing emails from 
g emails are still permitted. This allows the 
to he given destructions on how to remove the 



Outgoing email messages can be stopped by placing a stop on messages being sent 
from thefeuSet The hniler would snhse<|nently increase in si£e> as more requests to 
s«! emails are made. This has the disadvantage of taking ^p memory, but wonkl 
25 potentially allow fee recovery of valid messages at a later stage. 

AlteoMiveiy, if the teelmique is being implemented withm an email server, tire server 
cooM simply refuse any fruiter from that user (e.g. that hosi machine or 

email client) that attempt to seM email Further, the server could plaee a stop on 
3 0 sending any locally stored messages tot may have originated from thai nser. in speh a 
situation, it is likely that the hmi tmMm wOi store the triage (&g< the rnessa|e$ 
will he stored in the local otd box}> 
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It will fee appreciated fen t& .above description that the peifdnhas&e -of the'- VPMS or 
YAPS Is depemtel isposs nus$b$r of panuneiers, which .'SXist both' variables and 
tkeshoMs> Altering such parameters will act to vary the .sensitivity of the virus 
S detection or viri*% the severity with propagation is tfeotfei For instance, if fee 
record used to indicate identities indicative of hosts to which data fe been sent by the 
first host is decreased in size, then lite testrkttoB or "throttling" or virus detection 
melted will bo made sev^ i.e. data passage will fee more limited and/er more 
warnings indicative of viral activity are likely to neeim 

10 

However, &e present tevMp : &ave appreciated that in some eireunistanees, it can be 
advisable to vary the parameters. 

For instance, the parameter can be varied with the ti me of day. For instance, the 
IB pa«Beters could be syslematicsliy^ 

of a day. Such a technique could be used, for instance to pro vide more severe 
throttling or viral detection outside of the working hours (when Bormal network trafSc 
k likely to be lower), 

3 0 If desired 5 an extra parain etcr could be introduced corresponding to a perceived threat 
level This could he implemented by a system admiais tratoiv or altemaii vely might be 
implemented M automatic detection of the rest o f the network e,g, when the rest of the 
iietwrfc is believed to be under vims attack, then the threat level parameter is 
increased. A^'liiglr ihrest llc^el -jpor^ncicsr will eom^pond to the parameters being 

2$ adjusted to provide more severe throttling or viral detection on a host computet; 

It m conceivable that some viruses might attempt to spread wiii 1st remaining 
undetected or relati vely unimpeded by operating at levels (i.e. sending new requests) 
j ust less ihap that would be detect&hle or throttle. In order to fed! such viM attacks 
Bo that attempt to **ride the thrcsliaM" Vibe parameters may be changed randomly fey small 
am«tl> Alternatively* the parameters may be pulsed hciween parameters thai 
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provide a severe operating regime and those that provide a more rdnmi oprnMrng 
regime. 

Whether or not the parameters are varied as a .fenctiosi lime, it is desirable to be able i® 
5 detemi ne parameter tlM. efftetively detect ot Emit fee propagation of viruses within a 
network, Sneh a del ermination can be performed automatically* hy proyidkg a sat 0F 
data corresponding io normal network traffic (this set can either be pre-recorded, or 
can be collected 'live" as the network operates), A cost fimciionis ten provided, 
toehidmg bdications of desired perfemmnce of the VAPS or VPMS, and desired 
10 trends in parameters, eg. which parameters can be altered, and by bow meek An 
automated search is ttei conducted to find the optimum set of parameiers and 
parameter values given the set of data ori network tmffie. The automated search 
algorithm can take a number of forms, and may use techniques such as hill climbing, 
or simulated annealing, or it may be an evolutionary algoiitta, 

is 

All of the features disclosed in this speeifieation (mclnding 
ahsiraet and drawmp), and/or all of the slop of My method or process m disclosed, 
may be combined hi any combination, except combinations where at least some of 
such features and/or steps a^ mutnally exelusim 

20 

Each feainre disclosed k ihkspeeifi^^ 

abstract a^d drawings) may be replaced by alternati ve features servmg the same, 
ec|nivaient or similar purpose, unless expressly stated otherwise, unless 
expressly stated otherwise, each feature di sclosed i s on^ example only o f a geome 
■2-s series of equivalent or similar features. 
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CLAIMS 

! > Aitftetfeod of 0p^mtin;g a host m a network of a plurality of hosts, comprising; the 
steps of: 

5 receiving a roquet to data to a number of Qihfir .f * destmatioTi''} hosts; 

comparing the number of destination hosts in the request with the value- of a 
parameter; 

if the number of destination hosts is greater than the pax^metor value, Inhibiting 
transmksion of at least pa rt of the request; 
i o fee value of the parameter feeing reduced with each iraasoiissioii of a 

request to a destmafen host, m&. incremated with iM : |^age of each time interval in 
which bo mquests are transmitted. 

2. A method according to claim 1 wherein inhibiting transmits ion of at least pari of 
is the request comprises the step of diverting at. .teas* part of t&s. fittest to. a #Iay !?ufe,. 

3 . A Method ^cording to claim 2 &rtMr comprising the step of transmitting fee 
m^oest k the delay buffer wheo the value of the parameter is incremented to a value 
equal to thfc'msmbgr of destination hosts identi fied in the at least part of the xeqMSt in 

20 the delay buffer, 

4. A method according tn claim 1 wherein i f the number of destination hosts is 
equal to or less item the value of the parameter, the request is transmi tted. 

2B 3, A method according to claim 1 wherein tlie requesi is m email apeei^ng 
mnltlpte recipents. 

& A method according to claim 5 wherein transmi ssion of an email to mul tiple 
lecipie^ the aforesaid multiple number of requests. 

3 0 

7, A method accordi ng to claim 1 wherein upon ir^sm ission of a request the 
parameter is reset to &sro. 
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8 , A method according^ to claim S wherein the mulMpk r^cipimt email is processed 
m a plurality o f single recipient emaiK aftd tlie email i% sent to -a number of destiiiatlon 
hosts equal to the : value of the parameter, 
S 9. -A method acOTdmg to claim 5 wherein the mp!tip!<j recipient mml is pmoessed 
as a single email 

1 0. A method accoMing to claim 9 wherein the email is delayed until sufficient time 
intervals have passed m which no requests are transmitted lor the parameter to be 
10 e*p&i to the mm*er of mquests in fee tefe 

1 L A method aecording ta claim I wherea the parameter has a predetermined 
maximum value determined in accordance with a pollcv; 

IS 1 2. A method according to claim 1 wherein upon transmission of a request the 
p a«eter is clecremcBied by a number equal to the numher of trrasmltted requests, 

13. A method according to claim 1 2 wherein the parameter has a minimum value of 
sere, 

20 

14, A computing entity adapted to process a request to send m email to multiple 
recipients by: 

comparing the number of reeipienis in the request with the value of a parameter; 

if the number of recipient inhibiting 
as transmission of the message to at least some of the recipeuts; 

adjust the value of fee parameter in accordance wi th a policy by reducing U with 
eaeh transmission of a rei|ueM to a destioadon host, and incrementing it wife the 
passage of each time interval fe which m> requests are transmitted 

3 o IS. A computing entity according to claim 14 w herefe the entity k a server, 

14 A computing entity aee^rdini to claim 14 wherein the entity Is a client, 
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